Access to web services

ABSTRACT

The present invention provides a method, apparatus and computer program product which enable a web service gateway which provides support for business services which are described using a particular document format, for example Web Service Definition Language (WSDL), to further provide support for business services which are described using a different document format, for example in a business to business (b2b) profile such as specified by RosettaNet. The business service provides its profile to the gateway which generates a document from the profile and then uses the generated document to enable a web client, which recognises the document format but not the profile format, to access the web service via the gateway.

FIELD OF THE INVENTION

The present invention relates to web services and more particularly toproviding access to web services via a web service gateway.

BACKGROUND TO THE INVENTION

Over recent years it has become commonplace for a business to provide aweb site on the Internet which, for example, enables a web client topurchase goods from the business over the world wide web. Following onfrom this success it has more recently become a requirement to handlemore complex e-business applications on the Internet which, for example,enable business to business communication and this requirement has beensatisfied by the arrival of web services. Web services are modular andenhanced e-business applications that enable programmatic interactionbetween applications across the Internet.

A web service may, for example, be based on shared, open, and emergingtechnology standards and protocols, such as SOAP (Simple Object AccessProtocol), UDDI (Universal Description, Discovery and Integration), andWSDL (Web Service Definition Language). In this environment web servicescan communicate, interact, and integrate with heterogeneousapplications, irrespective of their implementation formats, therebyenabling web services to interact with one another across the Internetto facilitate dynamic integration between businesses, suppliers,partners, and customers.

For example, a web service which provides an e-business applicationpublishes its URL in a well known UDDI directory. A client can thenobtain the URL from the UDDI directory and contact the e-business usingthe URL in order to obtain a WSDL document. The WSDL describes theinterface provided for clients by the service e-business application,one or more transport mechanisms each supporting a communicationprotocol, for example SOAP over HTTP (HyperText Transport Protocol) andan end point address for each transport mechanism. Once a web client hasthe WSDL it can invoke the interface via the specified end point usingthe communication protocol of the specified transport mechanism. Furtherif the client has an e-business application with which the servicee-business application may wish to communicate, the client and servicemay exchange WSDL documents in order to make this possible. Further, inorder to enable clients and web services to communicate when each uses adifferent communication protocol, a web service gateway is used totransform client requests from one communication protocol to another.

However, whilst many web clients and services have made use of the WSDLdocuments and a UDDI registry many other web services have made use ofother business to business (b2b) protocols, such as those specified, forexample, by RosettaNet, cXML, and the Internet Engineering Task Force(AS1 and AS2). These protocols enable business partners using the sameb2b protocol to communicate. However it is not currently possible for aWSDL aware web client, which communicates with web services based onWSDL documents, to carry out e-commerce with a business partner whichuses these other, non WSDL based, business to business protocols.

SUMMARY OF THE INVENTION

Accordingly, according to a first aspect the present invention providesa method for a web services gateway to enable a web client to access aweb service, the method comprising the steps of: receiving a profilefrom the web service, the profile containing a details of how tocommunicate with the web service and being in a format not recognisableto the web client; creating a document based on the profile, thedocument being in a format recognisable to the web client and containingdetails of how to communicate with the web service via the gateway; andproviding, to a third party, information relating to the web service anda location from which the document can be obtained by the web client;thereby enabling the web client to use the document to access the webservice via the web service gateway.

According to a second aspect the present invention provides a webservices gateway which enables a web client to access to a web service,the gateway comprising: means for receiving a profile from the webservice, the profile containing a details of how to communicate with theweb service and being in a format not recognisable to the web client;means for creating a document based on the profile, the document beingin a format recognisable to the web client and containing details of howto communicate with the web service via the gateway; and means forproviding, to a third party, information relating to the web service anda location from which the document can be obtained by the web client;thereby enabling the web client to use the document to access the webservice via the web service gateway.

According to a third aspect the present invention provides a computerprogram product comprising instructions which, when executed on a dataprocessing host, cause the data processing host to carry out the methodaccording to the first aspect.

The third party could, for example, be a UDDI directory although inpractice it could be any entity which provides information about webservices to web clients.

Optionally the document is created, based on the profile, on receipt ofthe profile from the web service. Alternatively the document is createdonly after it is requested by a web client.

Optionally the location at which the document can be obtained which isprovided to the third party is in a different web service gateway to theone which generated the document, but which also has access to thedocument. Alternatively the location, which is provided to the thirdparty, at which the document can be obtained is in the same web servicegateway which created it.

Preferably the gateway subsequently receives a request from a web clientfor the web service. Optionally the request includes details of thedocument and the gateway uses these details to match the request withthe profile of the web service. Alternatively the document created fromthe profile includes a location in the web service gateway which theclient can use to access the web service and which is associated withthe profile. As a result the location at which the client request isreceived can be used to match the request with the profile of the webservice. Either way, once the profile is known details from it are usedto convert the request to one suitable for sending to the web serviceand to send the converted request to the web service.

Optionally the gateway may then return to the web client. Alternativelyit may wait for a response to the converted request from the web serviceand then use the response to the converted request to trigger a responseto the web client request.

Preferably the document is a Web Services Definition Language (WSDL)document and further could be in any WSDL based format, for exampleWSDL4J (WSDL for Java) or XLANG (WSDL with extensions). Alternativelythe document could be in another definition language, for example CORBAIDL.

Preferably the profile is specified according to the RosettaNet businessto business standard. Alternatively it could be, for example, accordingto other business to business standards such as those specified by cXML,and the Internet Engineering Task Force (AS1 and AS2).

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described, by way of example only, withreference to a preferred embodiment thereof, as illustrated in theaccompanying drawings, in which:

FIG. 1 is a schematic diagram of a data processing environment in whichthe preferred embodiment of the present invention can be advantageouslyapplied;

FIG. 2 is a schematic diagram of an example web client sending a requestto a web service through a gateway based on use of a UDDI registry andWSDL documents according to the prior art;

FIG. 3 is a schematic diagram of an example of a web client sending arequest to a b2b service through a gateway based on use of a UDDIregistry and WSDL documents where the b2b service is implemented toRosettaNet standards;

FIG. 4 is a schematic diagram of generating a WSDL document to representa b2b service based on a b2b profile provided by the service accordingto RosettaNet standards.

FIG. 5 a is a flow diagram of the method followed by a gateway server onreceipt of a b2b profile from a b2b service;

FIG. 5 b is a flow diagram of the method followed by a gateway server onreceipt of a request from a web client for a b2b service;

Note that in the figures like numbers are used to denote like parts.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a block diagram of a data processing environment in which thepreferred embodiment of the present invention can be advantageouslyapplied; In FIG. 1, a client/server data processing host 10 is connectedto client/server data processing hosts 12 and 13 via a network 11, whichcould be, for example, the Internet. For example a web client programcould be executing on host 10 which is accessing a web service on host12 via a gateway server on host 13. Client/server 10 has a processor 101for executing programs that control the operation of the client/server10, a RAM volatile memory element 102, a non-volatile memory 103, and anetwork connector 104 for use in interfacing with the network 11 forcommunication with the other client/servers 12 and 13.

In the preferred embodiment which follows the document describing a webservice is a WSDL document. Note that a WSDL document contains detailsof the web service such as Port Type, Bindings, Ports, Messages, Typesetc. The Port Type and messages define the operations and associatedparameters provided by the web service, the Bindings specify thecommunication protocols supported by the web service, and the Portsspecify end point addresses for channels providing access to the webservice using the communication protocols.

Further note that the preferred embodiment considers a b2b serviceimplemented using the RosettaNet standard b2b protocol. According toRosettNet business partners exchange b2b profiles. A b2b profileincludes such information as one or more communication protocols to usefor communication with the business, one or more locations at which thebusiness can be contacted, and details of a Partner Information Process(PIP) and an XML Document Type Definition (DTD) which respectivelydescribe the exchange protocols and format of the operations which thebusiness uses. Further the RosettaNet standards specifies many standardPIPs and XML DTDs, for example PIP3A4 and XML DTD3A4, PIP3A4 specifyingthat a buyer sends a purchase order request operation to the seller andthe seller sends a purchase order confirmation operation to the buyerand XML DTD3A4 specifying the format of those operations. As a result,for example, a Book business which sells books may send its b2b profileto one or more business partners which may then use information from theb2b profile in order to purchase books from it. (RosettaNet and PIP aretrademarks of the RosettaNet organisation).

FIG. 2 is a schematic diagram of an example of a WSDL aware web client201 sending a request to a web service 206, herein denoted “eBook”,through a gateway 210 based on the use of a UDDI registry 218 and WSDLdocuments 208, 213, and 214, according to the prior art. The eBookservice 206 is available from a target server 205 which has a channel207 which supports communication using a communication protocol of SOAPover HTTP. The eBook service provides the ability to purchase booksusing a purchase order request from a client to whom the eBook servicesends a purchase order confirmation. Details of the eBook service aredescribed in a WSDL document WSDL1 208 which specifies Port Types andMessages which define the operations of PurchaseOrderRequest( ) andPurchaseOrderResponse( ), bindings and port for the channel 207 whichspecify a communication protocol of SOAP/HTTP, and an end point addressof the channel through which the service can be contacted. The targetserver 205 provides (230) WSDL1 208 to the gateway 210 which saves acopy as WSDL1 213. In the gateway WSDL1 213 is passed (231) to thegateway engine 212 which, for example, changes the binding and port ofthe eBook service channel to those provided by the gateway, therebyproducing (232) an new WSDL, WSDL1 a 214. In this example the gatewayhas two channels, a SOAP/Java Message Service (JMS) channel 215 and aSOAP/HTTP channel 216 (Java is a registered trademark of SunMicrosystems Inc.). The gateway then registers (233) the eBook servicewith a known UDDI directory 218 by providing to the UDDI directory thetype of the service and the URL of the servlet 211 from which a clientcan obtain a copy of the modified WSDL, WSDL1 a 214. The UDDI directorymay be known to the gateway, for example, through configurationinformation.

A web client process 201 is running an application 202 which wishes toaccess the eBook service. The client process includes a channel 203which provides a transport mechanism of SOAP over JMS. The applicationfirst accesses (234) the UDDI directory 218 to obtain details of a bookservice and in return receives details of the URL of the servlet 211 inthe gateway 210 from which the modified WSDL, WSDL1 a 214, of the eBookservice can be obtained. The client application 202 then requests (235)the WSDL document describing the eBook service from the servlet 211. Asa result of this request the servlet 211 obtains (236) WSDL1 a 214 andreturns it to the client application. Then, based on this document, theclient application requests the purchaseOrderRequest ( ) operation ofthe eBook service as specified in the Port Type of the WSDL documentusing a communication protocol of SOAP/JMS as specified in the bindingsof the WSDL document and directing the request to the end point addressof the SOAP/JMS communication channel as specified as a Port in the WSDLdocument. To make the request the client application 202 passes (237)the request to SOAP/JMS channel 203 in the client process which thenforwards it (238) to the SOAP/JMS channel 215 in the gateway server 210.

When the SOAP/JMS channel 215 of the gateway 210 receives this requestit passes (239) the request to the gateway engine. The request includesdetails of the WSDL document, WSDL1 a 214, which the client applicationused to make the request, and based on this information the gatewayengine discovers the original WSDL, WSDL1 213, which was used to createWSDL1 a. From WSDL1 the gateway engine then obtains the bindings andport for the eBook service and as a result passes the request to theSOAP/HTTP channel 216 of the gateway server giving details of theSOAP/HTTP channel 207 of the eBook server. The SOAP/HTTP channel 216then sends (241) the request to the SOAP/HTTP channel 207 of the eBookserver 205 which then passes (242) it on to the eBook service 206.

FIG. 2 also shows a second service 221, herein denoted “aBook”, whichprovides the same operations as the eBook service 206 but is implementedaccording to RosettaNet standards. As a result, according to the priorart, it cannot be accessed by the WSDL aware web client 201, eitherdirectly or via the gateway server 210, as the b2b profile is notrecognisable to either the web client 201 and gateway server 210 whichrequire a WSDL document, whereas the aBook service 221 is a b2b servicewhich is only described in a non-WSDL b2b profile 223.

FIG. 3 is a schematic diagram of an example of the WSDL aware web client201 of FIG. 2 sending a request to the aBook service 221 through agateway 210 based on use of UDDI directory 218 and a WSDL document,WSDLb2b 302, where the aBook service 221 is implemented to RosettaNetstandards, according to the preferred embodiment of the presentinvention. Note that in FIG. 3, where common reference numerals are usedwith FIG. 2, the associated function is the same as in FIG. 2. The aBookservice 221 is available from a target server 220 which has a channel222 which supports communication using a transport mechanism ofRosettaNet Implementation Framework (RNIF) over HTTP. The aBook serviceprovides the ability to purchase books using a purchase order requestoperation and a purchase order confirmation operation. Details of theaBook service are described in a b2b profile 223, which contains detailsof a Partner Interface Process (PIP) and XML Document Type Definition(DTD), one or more communication protocols which it supports, and one ormore end point addresses at which the business can be contacted. In thisexample the b2b profile 223 contains details of PIP3A4 and XML DTD3A4,the RNIF/HTTP channel 222 and an end point address for the RNIF channel.PIP3A4 contains details an exchange protocol which says that the buyersends a purchase order request operation to the seller and the sellersends a purchase order confirmation operation to the buyer, and XMLDTD3A4 contains the data form of the purchase order request and purchaseorder confirmation operations.

The aBook server 220 provides its b2b profile 223 to business partnerswith which it wishes to operate and in this example sends (311) itsprofile to a profiler 301 in the gateway server 210. The profiler 301then saves a copy 303 of the b2b profile 223 and uses information fromit to create (312) a WSDL document WSDLb2b 302 which contains details ofthe operations supported by the aBook service and bindings and port forthe channels supported by the gateway. In this example the WSDL containsdetails of the purchase order request and purchase order confirmationoperations and the SOAP/JMS and RNIF/HTTP channels, 215 and 304,supported by the gateway server 210. The gateway then registers (313)the aBook service with a known UDDI registry 218 by providing to theUDDI registry the type of the service and the URL of the servlet 211from which a client can obtain a copy of the WSDL, WSDLb2b 302.

The web client process which, in this embodiment, sends a request to theebook service works in the same way as in FIG. 2, the only differencebeing the WSDL document which is returned to the client applicationrequest (235) to servlet 211. Accordingly the client sends (238) apurchase order request operation to the SOAP/JMS channel 215 of thegateway server.

When the SOAP/JMS channel 215 of the gateway 210 receives this requestit passes (239) the request to the gateway engine 212. The requestincludes details of the WSDL document, WSDLb2b 302, which the clientapplication used to make the request. The gateway engine then passes(315) this information to the profiler 301 which finds (318) the b2bprofile copy 303 from which the WSDL document was created and returnsdetails from it to the gateway engine 212. The details include thelocation of the aBook service 221 and the protocol to be used in sendingrequests to it. As a result the gateway engine transforms the clientrequest from a SOAP/JMS request to an RNIF/HTTP request and thenprovides it to the RNIF/HTTP channel 304 which sends (317) it to theaBook service 221 via the RNIF/HTTP channel 222 of the aBook server 220.When the request is received by the RNIF/HTTP channel it forwards (318)it to the aBook service 221 which does not know that it did not comedirectly from the client application 202.

In summary, according to the embodiment of FIG. 3, for a business whichis implemented to RosettaNet standards service, the business providesits b2b profile to the gateway. The profile contains details of a PIPand an XML DTD (which contain details of the exchange protocols andoperations supported by the business), the communication protocols whichit supports and the address at which the business can be contacted. Forexample it may publish a B2B profile containing details of PIP3A4, XMLDTD3A4 and RNIF/HTTP. PIP3A4 contains details of a purchase orderexchange protocol which a says that the buyer sends a purchase orderrequest and the seller sends a purchase order confirmation and XMLDTD3A4 contains details of the format of the purchase order request andconfirmation operations. The gateway has a “profiler” which receives theb2b profile and creates a WSDL document based on the details containedin the b2b profile. A client then gets the WSDL and sends a purchaseorder request to the gateway, the gateway receives the request whichincludes details of the WSDL it obtained to make the request. A gatewayengine then intercepts the request and asks the profiler for details ofthe address of the business service to send to the request to, which theprofiler gets from the b2b profile used to generate the WSDL. Therequest is then forwarded to the web service using the communicationprotocol specified in the b2b profile.

Note that according to PIP3A4 after receiving a purchase order request abusiness partner first sends a receipt acknowledgement signal to theclient business partner. This is then followed by a purchase orderconfirmation to which the client business partner responds with areceipt acknowledgement signal. This can be achieved using normalprocessing as the request sent from client SOAP/JMS channel 203 to thegateway SOAP/JMS channel 215, and from the gateway RNIF/HTTP channel 304to the target business RNIF/HTTP channel 222, will include returnaddresses. These flows can be done asynchronously or synchronously forthe client and/or the target service. For example if a client sends asynchronous purchase order request (for example using SOAP/HTTP insteadof SOAP/JMS) to the gateway and wishes to receive the receiptacknowledgement signal as a synchronous response, the gateway can holdthe thread used to process the client request and use the receiptacknowledgement from the aBook service as a trigger to release thethread and return to the client.

Note that whilst the preferred embodiment has been discussed in terms ofPIP3A4 and XML DTD3A4 which relate to requesting a purchase order thereare many other PIPs and associated XML DTDs which are defined by theRosettaNet standard which could alternatively be used. For examplePIP1A1 and XML DTD3A1 for requesting account set-up, PIP1B2 and XMLDTD1B2 for requesting Authorisation status, PIP2A1 and XML DTD2A1 todistribute new product information etc.

Further note that whilst the preferred embodiment has been discussed interms of a b2b service which provides a b2b profile according to theRosettaNet standard, alternatively the b2b service could provide a b2bprofile or equivalent according to any other standard such as thisspecified by cXML, and the Internet Engineering Task Force (AS1 andAS2). According to the invention the requirement of the b2b service isto provide to the gateway sufficient information (in a non-WSDL format)for the gateway to build a WSDL document describing the service.Sufficient information comprises details of the interface supported bythe b2b client or service and a communication protocol and address touse when communicating with it.

Further note that whilst the preferred embodiment describes use ofSOAP/JMS, SOAP/HTTP and RNIF/HTTP channels by the gateway server, inanother embodiment one or more of these channels may be omitted and/orreplaced and/or added to. For example other additional/alternativechannels could provide communication using, for example, InternetInter-Orb Protocol (IIOP), IIOP Secure (IIOPS), HTTP, HTTP Secure(HTTPS), SOAP over JMS, Remote Method Invocation (RMI) over IIOP, XMLover JMS, SOAP over Simple Mail Transfer Protocol (SMTP), or EnterpriseJavaBean (JavaBeans is a registered trademark of Sun Microsystems Inc.).

Further note that the gateway of the preferred embodiment comprises aservlet 211, engine 212, and profiler 301. However, a skilled personwould be aware that the functionality provided by these components couldeasily be distributed amongst fewer or more components and conceptuallyare provided by a single component which is the gateway 210.

FIG. 4 shows how, according to the preferred embodiment of the presentinvention, WSDLb2b (302) is created based on a B2B Profile (303)received from a b2b service and a gateway channels profile (406). Theb2b profile (303) contains details of a Partner Information Process(PIP) and an XML Document Type Definition (DTD) which specify theservices provided by the b2b service. In this example the b2b profilecontains details of PIP3A4 and XML DTD3A4 which define the exchangeprotocols and format of the messages (operations) which are used in theexchange protocol, respectively. The gateway uses this information toobtain XML DTD3A4 (401) and PIP3A4 (404) which are publicly availabledocuments and therefore not necessary to include directly in the b2bprofile (303). XMD DTD3A4 is first converted (411) into an XML Schema(402) using a standard tool, for example Extensible Stylesheet LanguageTranslation (XSLT), and then information from the XML Schema (402)relating to the format of the operations (messages) is transformed andcopied (412) into a section (403) of the WSDL document (302) whichdescribes the format of the messages supported by the service.Information in PIP3A4 (404) is then transformed and copied (413) into asection (405) of the WSDL document (302) which describes the operationsand associated exchange protocols supported by the service. Finallyinformation relating to channels available in the gateway, for examplechannels 215 and 304 of FIG. 3, are added (414, 415) sections (407, 408)to the WSDL document (302) each of which specify the bindings for achannel in the gateway through which the service can be contacted.

FIG. 5 a is a flow diagram of the method followed by a gateway server onreceipt of a b2b profile from a b2b service, for example, with referenceto FIG. 3, the method of the profiler 301 on receipt of the b2b profile223 from the aBook server 220. At step 501 the gateway receives (311 ofFIG. 3) the b2b profile from the b2b service and at step 502 the b2bprofile received is used to generate (312 of FIG. 3) a WSDL document,for example, using a method as illustrated in FIG. 4. The WSDL documentdescribes the interfaces provided by the b2b service and the address ofchannels to which requests can be sent to the gateway server and detailsof and the protocols the channels support. Finally at step 503 thegateway provides (313 of FIG. 3) to a UDDI registry details of the b2bservice and a location in the gateway from which the WSDL can beobtained. The details of the b2b service provided to the UDDI registrymay then be used by a web client to identify a service which it wishesto use and may, for example, include details of the web service such asthe type of goods sold.

FIG. 5 b is a flow diagram of the method followed by a gateway server onreceipt of a request from a web client for a b2b service, for example,with reference to FIG. 3, the method of the channels 215 and 304,gateway engine 212, and profiler 301 on receipt (238) of a request froma client application 202 for a the aBook service 221. At step 510 therequest is received (238 of FIG. 3) by the gateway via one of thechannels it supports and at step 511 details of the WSDL document thatwas provided to the client for making the request are obtained from therequest. At step 512 the WSDL document identified is matched (318 ofFIG. 3) with the b2b profile used to generate it, for example at step502 of FIG. 5 a. Once the b2b profile has been identified informationrelating to the location of the b2b service and the protocols which itsupports are obtained from it and then, at step 513, this information isused to modify the request for sending to the b2b service, for exampleby changing the protocol from SOAP/JMS to RNIF/HTTP. However, note thatthe protocols used by the client and target service may be the same inwhich case the protocol used for the request need not be modified.Finally at step 514 the request is forwarded (317 of FIG. 3) to the b2bservice at the location specified in the b2b profile. Thus a web clientrequest based on a WSDL document has been received, modified andforwarded to a b2b service which is specified in a non-WSDL b2b profile.

Note, alternatively at step 502 of FIG. 5 a the address of the channelsto which request can be sent can be associated with the b2b profile usedto create the WSDL document. As a result steps 511 and 512 of FIG. 4 bwould not be required as the b2b profile could be obtained based on thelocation at which the request is received.

Further note, step 502 need not be carried out after receipt of the b2bprofile at step 501 and before providing details of the WSDL to a UDDIregistry at step 503. Alternatively the WSDL can be created on receiptof a request from a client for a copy of the WSDL, for example onreceipt of request 235 of FIG. 3 (not shown in FIGS. 5 a and 5 b).

Note that a skilled person would realise that the methods described inFIGS. 5 a and 5 b could be implemented in a variety of programminglanguages, for example, Java, C, and C++. Further a skilled person wouldrealise that once implemented the methods can be stored in a computerprogram product comprising or more programs, in source or executableform, on a media, such as floppy disk, CD, and DVD, suitable for loadingonto a data processing host and causing the data processing host tocarry out the methods.

The present invention provides a method, apparatus and computer programproduct which enable a web service gateway which provides support forbusiness services which are described using a particular documentformat, for example Web Service Definition Language (WSDL), to furtherprovide support for business services which are described using adifferent document format, for example in a business to business (b2b)profile such as specified by RosettaNet. The business service providesits profile to the gateway which generates a document from the profileand then uses the generated document to enable a web client, whichrecognises the document format but not the profile format, to access theweb service via the gateway.

1. A method for a web services gateway to enable a web client to accessa web service, the method comprising the steps of: receiving a profilefrom the web service, the profile containing a details of how tocommunicate with the web service and being in a format not recognisableto the web client; creating a document based on the profile, thedocument being in a format recognisable to the web client and containingdetails of how to communicate with the web service via the gateway; andproviding, to a third party, information relating to the web service anda location from which the document can be obtained by the web client;thereby enabling the web client to use the document to access the webservice via the web service gateway.
 2. A method according to claim 1comprising the further steps of: receiving a request from the web clientfor the web service, the request including details of the document;using the details of the document to match the request with the profilereceived from the web service; using details from the profile to convertthe request to a request suitable for sending to the web service; andsending the converted request to the web service.
 3. A method accordingto claim 1 wherein the details of how to communicate with the webservice via the gateway include a location in the gateway for the clientto use when requesting to access the web service, the location beingassociated with the profile and the method further comprises the stepsof: receiving a request, at the location, from the web client for theweb service; obtaining details from the profile associated with thelocation and using the details to convert the request into a requestsuitable for sending to the web service; and sending the convertedrequest to the web service.
 4. A method according to claim 2 comprisingthe further steps: waiting for a response to the converted request fromthe web service; and using the response to the converted request totrigger a response to the web client request.
 5. A web services gatewaywhich enables a web client to access to a web service, the gatewaycomprising: means for receiving a profile from the web service, theprofile containing a details of how to communicate with the web serviceand being in a format not recognisable to the web client; means forcreating a document based on the profile, the document being in a formatrecognisable to the web client and containing details of how tocommunicate with the web service via the gateway; and means forproviding, to a third party, information relating to the web service anda location from which the document can be obtained by the web client;thereby enabling the web client to use the document to access the webservice via the web service gateway.
 6. A gateway according to claim 5further comprising: means for receiving a request from the web clientfor the web service, the request including details of the document;means for using the details of the document to match the request withthe profile received from the web service; means for using details fromthe profile to convert the request to a request suitable for sending tothe web service; and means for sending the converted request to the webservice.
 7. An gateway according to claim 5 wherein the details of howto communicate with the web service via the gateway include a locationin the gateway for the web client to use when requesting to access theweb service, the location being associated with the profile and thegateway further comprises: means for receiving, at the location, arequest from the web client for the web service; means for obtainingdetails from the profile associated with the location and using thedetails to convert the request into a request suitable for sending tothe web service; and sending the converted request to the web service.8. A gateway according to claim 6 further comprising: means for waitingfor a response to the converted request from the web service; and meansfor using the response to the converted request to trigger a response tothe web client request.
 9. A computer program product comprisinginstructions which, when executed on a data processing host, cause thedata processing host to carry out the method as claimed in claim 1.